This is an automated cherry-pick of #2094

What problem does this PR solve?

Fix #1814
In #1723 we support switching position replication to gtid replication by combining previous GTID sets and their events in binlog files. However, if there are some gtid events that are purged, the switching progress will fail.

What is changed and how it works?

According to MySQL's official document 1

The set of transactions that can be found in the binary logs at any given time is equal to GTID_SUBTRACT(@@GLOBAL.gtid_executed, @@GLOBAL.gtid_purged); that is, to all transactions in the binary log that have not yet been purged.

and MySQL's official document 2

The set of GTIDs in the gtid_purged system variable (@@GLOBAL.gtid_purged) contains the GTIDs of all the transactions that have been committed on the server, but do not exist in any binary log file on the server. gtid_purged is a subset of gtid_executed. The following categories of GTIDs are in gtid_purged:

* GTIDs of replicated transactions that were committed with binary logging disabled on the replica.
* GTIDs of transactions that were written to a binary log file that has now been purged.

Gsets of gtid_purged are not in any binlog files but they are contained in gtid_executed. This can explain two things:

1. We can't get binlog events in gtid_purged, even if we continue the way of position replication.
2. The method of replication to current gtid_executed won't make the situation better. Upstream MySQL may still purge binlogs when we trying to catch events to gtid_executed.

So we can directly add gtid_purged in adjusted gtid sets to avoid MySQL error.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
  Use a slave MySQL whose previous gtids starts from 5 to test whether this PR works.

Related changes

• Need to cherry-pick to the release branch
• Need to be included in the release note